Aminet 28

home *** CD-ROM | disk | FTP | other *** search

/ Aminet 28 / Aminet 28 (1998)(GTI - Schatztruhe)[!][Dec 1998].iso / Aminet / util / libs / MMULib.lha / MMULib / ReadMe < prev next >

Wrap

Text File | 1998-10-04 | 17.5 KB | 439 lines

The mmu.library project © 1998 the mmu.library development group, THOR ----------------------------------------------------------------------------- Release 0.05 ------------ -Fixed a bug in the context management, memory property setup routine. Due to a typo, one register was assigned in the wrong way and messed up the routine. Just the joy of assembly! Sigh. "NUTS" seems to work flawlessy, though. Thanks to all the testers, locating and fixing this bug was just a matter of ten minutes. Release 0.04 ------------ Bugs fixed: -Rewrote the MMU table parser completely. The old one was simply too broken to fix it. The "New Universal Table Scanner" - or short "NUTS" (-; contains very little hardware dependent code, so I was able to check most of it without having a '040 or '060 MMU available. Should hopefully work now. It took one day to debug all that, all the special cases... It's really a recursive monster algorithm, hope the comments are somewhat useable. -Added a check for the EC040. Thanks for the insight, Simon! At that time, no check for a EC030 vs. a real 030 is available. The motorola specs say I've to build a MMU page and check what happens... Something like this might be implemented in a future version, as soon as the table scanner and the table builder are working. -Added an explicit version check for MMUScan. -Added a memory flush in MMScan. "Avail Flush" is no longer required. -Added the "TestMMU" program for debugging purposes. More on that below. Release 0.02 ------------ Bugs fixed: -Due to a typo in the 68040/68060 startup code, the translation control register wasn't written to the right place, leading mis- interpretations of the library. -The 68040 specific part did not call the 68040 table scanner, but the 68060 stuff. -The library clean up code did not fill in the translation control register correctly for the 68040 and 68060. -The library did not accept "exotic" transparent translation settings. Unfortunately, these are not as uncommon as I believed. Some boards seem to translate a part of the memory transparently for read access only. I've no idea what this might be good for. But anyways, the memory regions transparently translated are now "mapped out" by the mmu.library and marked as unusable for further manipulation. This means specifically that a huge part of the available address space may be unavailable for virtual addresses. A future version of the libray may re-introduce the integration of the TTx registers into the mmu table, but up to then I don't like to risk anything. What is this: ------------- The mmu.library provides functions for MMU related operations as write- or read-protecting certain areas of memory for a given set of tasks, or marking memory regions as "swapped" virtual memory support. It offers an abstraction level on top of the actual MMU and a unified interface for MMU purposes. The MMU lib does NOT implement virtual memory, that's the purpose of another library - the memory.library. There's no much reason why any application except the memory.library and probably some debugging tools should call this library directly. The memory.library functions on top of this library should suffer for "all day purposes". The goal of the mmu.library is to provide an "abstraction layer" on top of the hardware, to allow programs to make use of the memory management hardware of the more advanced members of the MC68K processor family. Programs using the functions of the mmu.library do not need to modify the MMU tables directly and hence will not conflict with each other. The mmu.library interface provides all necessary functions to do that. This will allow programs like Enforcer and VMM to cooperate nicely with each other, provided both use this library. Since writing the mmu.library is a tough job, I need your help! I've only a single oldish MC68030 40Mhz system at home, but the mmu.library is supposed to support all members of the MC68K family (the 68851, 68040 and 68060 MMUs). Since I don't have a testing system available, I need your help - writing system software without being able to debug is "a bit" tricky. What can I do as a non-developer: --------------------------------- Simple. Stop all disk access, upack the archive to the RAM disk, then open a shell and enter assign LIBS: ram: add then run the "MMUScan" program. Watch what happens: The program should output a list like the following: MMUScan 0.05 (04.10.98) © THOR. Internal use only, no commercial use. 68030 MMU detected. MMU page size is 0x400 bytes. User root pointer: 0x800000020023f870 Supervisor root pointer: 0x0000000000000000 Translation Control : 0x80a08680 Data Transparent translation 0: 0xffff0777 Data Transparent translation 1: 0xffff0777 Inst Transparent translation 0: 0x00000000 Inst Transparent translation 1: 0x00000000 Memory region: 00000000 to 000003ff invalid, ID 00000000 global Memory region: 00000400 to 001fffff cache inhibited global Memory region: 00200000 to 009fffff copyback cache mode global Memory region: 00a00000 to 00bbffff invalid, ID 00000000 global Memory region: 00bc0000 to 00bfffff cache inhibited global Memory region: 00c00000 to 00d7ffff invalid, ID 00000000 global Memory region: 00d80000 to 00dfffff cache inhibited global Memory region: 00e00000 to 00e7ffff invalid, ID 00000000 global Memory region: 00e80000 to 00ebffff cache inhibited global Memory region: 00ec0000 to 00efffff invalid, ID 00000000 global Memory region: 00f00000 to 00ffffff write protected copyback cache mode global Memory region: 01000000 to ffffffff invalid, ID 00000000 global This is the definition of your MMU profile, giving the properties of each page in memory. Watch out for possible crashes or other problems. If anything goes wrong, please write down the guru number and contact me. The email is above. If you see a guru - shouldn't happen any more - then please run the PrintTTX program in this directory instead and send me the output. What can I do as developer: --------------------------- What about joining the mmu.library development group? This is just a couple of people contributing to this library by writing code and exchanging their wisdom by EMail. It's a non-profit organization that works on the development of this library. If, whenever, this library becomes a commercial product, you'll get paid, of course. However, the current library, as it is, is planned to be freeware, so don't expect money. It doesn't look like there's currently a market for this library project, unfortunately. Contact me at thor@math.tu-berlin.de if you want to join this group. What can be done just now is to run this library on your machine and find and correct bugs. As I said, I haven't tested the 68851, the 68040 and 68060 parts at all. The source of the library is included to help you debugging it, but please don't make modifications without contacting me. What is required to build the library: -------------------------------------- The library is build by two assemblers, the DevPac and the Freeware assembler PhxAss which can be found on the AmiNet. I still prefer the DevPac because it's Macro capabilities, even though it doesn't support all the 68060 functions I need to get hands on. Hence, the general-purpose functions of the library are assembled with DevPac - the .asm files - , the processor specific routines - in the .a files - use the PhxAss, however. A make utitilty would do good, the makefile is included. "Make debug" will build the binary. Two assigns need to be setup, MMU: and TMP:. The sources should be copied to TMP: on installation, the makefile will make backups to MMU: automatically. A linker is required to link the object codes toghether. The makefile uses the "SLink" linker of the SAS C package, but the "BLink" PD linker of the "Software Destillery" should work fine, too. It is available from the Aminet, for example. Just edit the makefile and replace "SLink" with "BLink". A C compiler is needed to compile the example program "MMUScan". Every C compiler should do fine provided the contents of "Include" is copied to the include directory of your compiler installation, or this directory is added to the include search path. What is in this distribution: ----------------------------- Autodocs: The preliminary version of the autodocs of the mmu.library and the memory library, as well as a file describing some planned implementation details. Include: The includes for a C compiler as well as the ".fd" file for the library functions written so far. In detail: mmu/mmubase.h The library base as well as the defines describing the MMU types found. mmu/context.h Describing the main structure of the mmu.library, the context. This defines, too, the memory properties that can be set by the MMU, as non-cacheable or write protected. mmu/config.h Describes an internal-use-only MMU configuration structure. A final edition of this library won't include this file. mmu/alerts.h Defines the guru-mediations that can be thrown by the library. mmu_lib.fd The function descriptor file written so far. clib Prototypes for the library functions. pragmas Pragmas for the library functions. Created with FDToPragma. Should work with every compiler. proto Prototypes for the library, includes the clib and the pragma file. C_Sources: C sources of sample programs. That's currently only the MMUScan program that prints the MMU configuration, the page size, the type of the MMU found and its hardware configuration. MMUScan: The ready-for-use MMUScan program. Quite long because I compiled this with the standard link-library I/O functions. Could be done much better, but this is only a test program anyways. TestMMU: This program is purely for debugging purposes. If you run it, you won't see any specific action. It simply opens the library manually and executes the library init function in the task context of the calling program. Hence, this program can be used to step thru the lib-init function with a standard debugger without the need to catch "ramlib". The "NUTS" table scanner is part of the library init function and the most critical part. If you still discover bugs and want to try, then load this program into a debugger of your choice, and step thru it. Lib_Sources: The library sources. This is more or less a direct copy from my harddisk. Includes the assembly sources, the assembly headers used to assemble this, the Makefile and the object files if you don't want to re-assemble everything. Contains, too, some startup- files used for my assembler setup. Not necessarely required. Needless to say that everything in here is "private" in the sense that no program using the mmu.library should depend on the implenentation details defined by these files. The ".a" files are assembled by PhxAss, ".asm" is done by "DevPac" and ".i" are the includes. In detail: Project-Startup: Makes necessary assignments and copies the sources into a temporary directory. Run at my system as soon as I launch the assembler. Shell-Startup2: A shell script run by the "Project-Startup" that makes a few additional setups. Makefile: The makefile used to assemble and link this program. mu_version.i: Defines the version of this library. mu_lib.i: The detailed library header structure. mu_lib.asm: The library initialization and shutdown code, the resident structure of the library and some few stub funtions. mu_alerts.i: Defines the gurus thrown by the library. mu_detect.a: The MMU auto detection logic. Should work fine (better than the enforcer code which crashes on a plain MC68020 without MMU...) mu_service.asm: Service routines. Currently, a routine to allocate library aligned to page boundaries. Not yet used, but still there. mu_pool.asm: Memory pool functions. Since the exec functions are bugged unless SetPatch is installed, I prefer using my own. mu_context.i: Describes the MMU library main structure, the (MMU)-Context, as well as the MMU memory property flags and the map node structure used for the abstraction level of the MMU tables. mu_context.asm: Context management and manipulation functions, including a function that builds the default MMU mapping if no MMU table was found. mu_loadlib.asm: This is not linked to the library. It's a tiny assembly source that loads the library to allow a standard debugger to step thru. mu_tableparse.asm: The "NUTS" table scanning algorithm, used to build the MMU table abstraction from the hardware MMU table. Is even able to scan "long" descriptors with limits of a '030 system (that, at least, I tested). Should also handle the '040 and '060 MMU tables. If "MMUScan" still hangs, HERE's the bug. mu_descriptor.i: Another abstraction layer used by "NUTS" to describe a hardware table descriptor. mu_851.a: 68851 specific routines, load and save the MMU configuration, interprets hardware MMU table descriptors and converts them into a hardware-independent format for "NUTS". mu_030.a: 68030 specific routines. mu_040.a: 68040 specific routines. mu_060.a: 68060 specific routines. Asm_Includes: I'm usually too lazy to include the system header files when writing in assembly. It usually takes ages to include them... These includes just define the library offsets of some standard libraries without the anoying "_LVO" I can't stand (what is this supposed to do anways?). It also defines a set of sophisticated macros for the DevPac assembler (Macros.asm). An older version of these can be found on my web page. Unfortunately, the PhxAss Assembler isn't powerful enough to assemble these. (Sigh.) Known bugs and problems of this implementation: ----------------------------------------------- Things that require testing: - 68851, 68040 and 68060 code completely untested. I NEED YOUR HELP! However, looks like this works, after checking your outputs. - Parsing of the transparent translation registers untested. Seems to be working, at least for the 68030 TTR registers. - Parsing of setups which make use of a distinct user/supervisor MMU table. Things not yet implemented: - Building and modification of MMU tables. - The exception handler (tricky!) - The context switch routines. - An interface to the 68060 library required to adapt changes of this library into the mmu.library page tables. Things the current design does not allow: - MMU tables using the function codes. The amiga design shouldn't allow this anyways, but I don't know whether there's a board that makes use of them. (Does'nt look like, though). - Boards with two different MMU's on board. I've heard some rumours that there are actually 68040 boards with an additional 68851. The current library assumes a 68040 MMU. - The current implementation does not yet check completely whether an "EC" type processor (without an MMU) is on-board. This check should work for the 68060 since there's a hardware register for it, and there's now even a test for a EC040 which hopefully works, but there's NO test for the EC030 because I wasn't able to find a simple one. More might follow as soon as the table scanner and the table builder is up. I would really enjoy if someone (Ralph Schmidt?) could give me some internal information about the P5 boards and their MMU usage. Especially, the function calls and the design of the 68040 and 68060 library would be of great help, as well as some specifics of the DMA problems of the Enforcer and the various versions of the 68060 library (Michael Sinsz should know this?). Any kind of information will be appreciated! Debugging: ---------- Yes, that's a problem of its own. Obviously, the MMU library uses some "heavy magic" supervisor code which is not available for a standard monitor. Even though the DevPac "MonAm" is a nice and powerful debugger, it's not powerful enough for these tricks. There's currently - up to my knowledge - only one debugger that can do this for you, and that's my own... (-; Check the Aminet and my web-page for COP, then read the documentation. If, after reading, you STILL want to use it, you're the right guy for this job... (-; COP might be setup to load the symbols of the library, to help you a bit. A printout of the critical part - NUTS to be specific - might be helpful, too. Recommended reading: -------------------- The following books are recommended reading: Motorola 68030 Enhanced 32-bit Microprocessor User's Manual MC68030UM/AD Rev.3 Motorola 68040 User's Manual M68040UM/AD Rev.1 Motorola 68060 User's Manual M68060UM/AD Rev.1 Motorola M68000 Family Programmer's Reference Manual M68000PM/AD Rev.1 Amiga Hardware Reference Manual, 3rd ed. Addison-Wesley Publishing Company, Inc. ISBN 0-201-56776-8 Amiga ROM Kernal Reference Manual, 3rd ed., Volume "Libraries" Addison-Wesley Publising Company, Inc. ISBN 0-201-56774-1 The Amiga Guru Book, 2nd Ed. Ralph Babel, Taunusstein 1989,1993 Additional sources: The Amiga Developer CD V1.1 (newer versions are already available, but 1.1 is good enough). Final words: ------------ The mmu.library and the memory library will be my last project for the Amiga. It depends a bit on what happens with the Amiga in the next two years whether a PPC version of this library is required or not; hence, after all, this can't be much more than a toy project that came several years too late. However, as it looks now, Amiga goes PC. I'm currently not willing to support this step and the Intel/Microsoft illnesses. \begin{sarcastic} While Commodore just dug the grave for the Amiga, Gateway is turning it into a zombie. \end{sarcastic} So long, Thomas